i'm wondering why pyrefly instead of ty.
fyi. ty and ruff are from the same company, i guess they will work better together?

some articles i read earlier this year:
https://blog.edward-li.com/tech/comparing-pyrefly-vs-ty/
https://www.infoworld.com/article/4005961/pyrefly-and-ty-two-new-rust-powered-python-type-checking-tools-compared.html

also, tbh, i think it's too early to introduce pyrefly nor ty to this widely-used nvimdots since their both in their early stage.

Make all of them as configurable options seems a better choice?

tbh, i think we can close this PR now and wait 'til they got more mature

Make all of them as configurable options seems a better choice?

Doing a refactor for this now, later I will PR again.

sry for the little bugs here, please review again. 🤕

Also, I'm thinking about whether the LSP config should be aligned with original pylsp config.
In the last commit, the config is just the default config with all three plugins pyrefly, ty and ruff.

Sorry I'm so busy that I haven't been able to participate much.

Personally, I don't know if I need to change it from pylsp (I've never used pyrefly but...).
Do we need to switch from pylsp+ruff quickly?

am concerned that if exceptional handling is permitted in a particular language, it will lead to the possibility that the introduction of unstable LSPs will also be permitted in other languages in the future.
I think this could lead to bloating of the code.
Therefore, rather than merging exception handling, it is better to have the user verify with override and then create PR again when it matures.

For now, I would like to make a proposal to put it on hold for discussions, projects, etc.

Sorry I'm so busy that I haven't been able to participate much.

Personally, I don't know if I need to change it from pylsp (I've never used pyrefly but...). Do we need to switch from pylsp+ruff quickly?

am concerned that if exceptional handling is permitted in a particular language, it will lead to the possibility that the introduction of unstable LSPs will also be permitted in other languages in the future. I think this could lead to bloating of the code. Therefore, rather than merging exception handling, it is better to have the user verify with override and then create PR again when it matures.

For now, I would like to make a proposal to put it on hold for discussions, projects, etc.

I also agree with the idea of making it a proposal. Happy to help with this, anything I can do further?

I would like to open the pr again when its more suitable to swtich to new python lsp, closing this now.

i'm wondering why pyrefly instead of ty. fyi. ty and ruff are from the same company, i guess they will work better together?

some articles i read earlier this year: https://blog.edward-li.com/tech/comparing-pyrefly-vs-ty/ https://www.infoworld.com/article/4005961/pyrefly-and-ty-two-new-rust-powered-python-type-checking-tools-compared.html

also, tbh, i think it's too early to introduce pyrefly nor ty to this widely-used nvimdots since their both in their early stage.

Recently, I tried both of them. I guess now the pyrefly is more implemented then ty, base on my own basic using experience. The pyrefly would correctly imply type from basic python std lib most of the time. On the contrary, ty contains loads of list[@todo] things.
What's more is that by their claim on its official website that its been tested with Meta's own codebase at scale. I guess maybe its time for us to reopen the PR again?

What's more is that by their claim on its official website that its been tested with Meta's own codebase at scale. I guess maybe its time for us to reopen the PR again?

looking cool! there's also a new blog of the pyrefly devs tested on numpy. sounds solid for me!

but i have some suggestions for the pr:

1. since now pyrefly is not that "experimental" for python, i think we can remove the extra settings in lua/core/settings.lua and just add in "lsp_deps".
2. keep lua/modules/configs/completion/mason-lspconfig.lua as usual and config ruff in lua/modules/configs/completion/null-ls.lua for none-ls is our only way to config linters and formatters.
3. clean up extra config for pylsp like in here.

What's more is that by their claim on its official website that its been tested with Meta's own codebase at scale. I guess maybe its time for us to reopen the PR again?

looking cool! there's also a new blog of the pyrefly devs tested on numpy. sounds solid for me!

but i have some suggestions for the pr:

1. since now `pyrefly` is not that "experimental" for python, i think we can remove the extra settings in `lua/core/settings.lua` and just add in "lsp_deps".

2. keep `lua/modules/configs/completion/mason-lspconfig.lua` as usual and config `ruff` in `lua/modules/configs/completion/null-ls.lua` for `none-ls` is our only way to config linters and formatters.

3. clean up extra config for `pylsp` like in [here](https://github.com/ayamir/nvimdots/blob/367008a5a4be1998b0b7d29524a4e750dc022d99/lua/modules/configs/completion/mason-lspconfig.lua#L128-L178).

I will try to reopen and PR again, thanks for the suggestions. It's been my first time to contribute to a neovim project, if there's problems just let me know.

@CharlesChiuGit After a little bit of research, now none-ls regards ruff as a LSP instead of a formatter.

Hence, we have two options:

1. Add none-ls-extra as a source of formatter and linter
2. As the repo mentioned and now ruff also regards itself as a LSP, we install is via mason

Guess the second options is more reasonable for me, I would like your idea on this.

Hence, we have two options:

1. Add none-ls-extra as a source of formatter and linter
2. As the repo mentioned and now ruff also regards itself as a LSP, we install is via mason

Guess the second options is more reasonable for me, I would like your idea on this.

cool, sounds gd to me. but since we block server formatting capabilities by default, don't forget to add ruff to settings["server_formatting_block_list"] in settings.lua and set it to false.

u can check why we block server formatting by default in https://github.com/ayamir/nvimdots/wiki/Knowledge-Garden#-lsp-related-issues.

@CharlesChiuGit Thanks for your help, fixed now.